In a distributed application, a desktop application interacts with a server to receive various services. For example, in a messaging application (e.g., an email application), a client desktop receives messaging services. In a small company environment, a single server can be deployed to provide services for clients in a single location. As a company grows, a single server system is no longer sufficient to maintain a working messaging system under all conditions.
In a large scale enterprise-class messaging solution (e.g., a corporate email network), a number of server components are distributed geographically. Typically, a server is required for each geographic location and each server interacts with an associated database. The database can include mailboxes, addresses for all company users, stored email, stored attachments, etc.
Messaging services have become mission critical applications to many enterprises. As a result, failure handling requirements have increased to reduce messaging outages. However, a typical large scale messaging service architecture still exhibits characteristics of a single server solution in that one or more databases are typically associated with a single server. Thus, in the event of a failure of the server, access to its database(s) is also lost.
This system architecture creates difficulties in implementing individual database failover and switchover. If a single database fails, an outage results and a failover recovery operation is performed to recover the database. However, if a number of databases are also associated with the server, the failover operation creates an outage for users of those other databases. As messaging systems continue to evolve, such problems result from attempting to retrofit high availability support into existing “legacy” architecture.